SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Hypertext Transfer Protocol</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading">Hypertext Transfer Protocol</h1>

</header>

</div>

HTTP

/* start https://fr.wikipedia.org/ */

.mw-parser-output .entete.communication{background-image:url("./_mw_/Picto_infobox_antenna.png")}

/* end https://fr.wikipedia.org/ */

</style>

<div>Hypertext Transfer Protocol</div>

</div>

</div>

<div class="legend">Début d'une <a href="Adresse_web" class="mw-redirect" title="Adresse web">adresse web</a> HTTP dans la <a href="Barre_d'adresse" title="Barre d'adresse">barre d'adresse</a> d'un <a href="Navigateur_web" title="Navigateur web">navigateur web</a>.</div>

<table><caption style="">Informations</caption>

<th scope="row"> Fonction

</th>

<td>

Transmission d'<a href="Hypertexte" title="Hypertexte">hypertexte</a></td>

</tr>

<tr>

<th scope="row"> <a href="Sigle" title="Sigle">Sigle</a>

</th>

<td>

HTTP</td>

</tr>

<tr>

<th scope="row"> Date de création

</th>

<td>

</tr>

<tr>

<th scope="row"> Auteur(s) / Autrice(s)

</th>

<td>

<a href="Tim_Berners-Lee" title="Tim Berners-Lee">Tim Berners-Lee</a></td>

</tr>

<tr>

</th>

<td>

80</td>

</tr>

<tr>

</th>

<td>

</tr>

</tbody></table>

</div>

L’Hypertext Transfer Protocol, généralement abrégé HTTP, littéralement « protocole de transfert <a href="Hypertexte" title="Hypertexte">hypertexte</a> », est un <a href="Protocole_de_communication" title="Protocole de communication">protocole de communication</a> <a href="Client-serveur" title="Client-serveur">client-serveur</a> développé pour le <a href="World_Wide_Web" title="World Wide Web">World Wide Web</a>. <a href="Hypertext_Transfer_Protocol_Secure" title="Hypertext Transfer Protocol Secure">HTTPS</a> (avec S pour secure, soit « sécurisé ») est la variante sécurisée par le <a href="Chiffrement" title="Chiffrement">chiffrement</a> et l'<a href="Authentification" title="Authentification">authentification</a>.

HTTP est, avec <a href="Hypertext_Markup_Language" title="Hypertext Markup Language">HTML</a> et les <a href="Uniform_Resource_Locator" title="Uniform Resource Locator">URL</a>, une des trois inventions fondamentales de <a href="Tim_Berners-Lee" title="Tim Berners-Lee">Tim Berners-Lee</a> pour créer le <a href="World_Wide_Web" title="World Wide Web">World Wide Web</a>.

Les <a href="Client_HTTP" title="Client HTTP">clients HTTP</a> les plus connus sont les <a href="Navigateur_web" title="Navigateur web">navigateurs Web</a>. HTTP est aussi utilisé hors du Web pour mettre en œuvre les <a href="Interface_de_programmation" title="Interface de programmation">interfaces de programmation</a> distribuée fondées sur <a href="SOAP" title="SOAP">SOAP</a> et <a href="Representational_state_transfer" title="Representational state transfer">REST</a>.

<div class="mw-heading mw-heading2"><h2 id="Historique">Historique</h2></div>

HTTP a été inventé par <a href="Tim_Berners-Lee" title="Tim Berners-Lee">Tim Berners-Lee</a> avec les <a href="Adresse_Web" class="mw-redirect" title="Adresse Web">adresses Web</a> et le langage <a href="Hypertext_Markup_Language" title="Hypertext Markup Language">HTML</a> pour créer le <a href="World_Wide_Web" title="World Wide Web">World Wide Web</a>. À cette époque, le <a href="File_Transfer_Protocol" title="File Transfer Protocol">File Transfer Protocol</a> (FTP) était déjà disponible pour transférer des fichiers, mais il ne supportait pas la notion de <a href="Format_de_donn%C3%A9es" title="Format de données">format de données</a> telle qu'introduite par <a href="Multipurpose_Internet_Mail_Extensions" title="Multipurpose Internet Mail Extensions">Multipurpose Internet Mail Extensions</a> (MIME). La première version de HTTP était très élémentaire, mais prévoyait déjà le support d'en-têtes MIME pour décrire les données transmises. Cette première version reste encore partiellement utilisable de nos jours, connue sous le nom de HTTP/0.9.

En <time class="nowrap date-lien" datetime="1996-05" data-sort-value="1996-05"><a href="Mai_1996" title="Mai 1996">mai</a> <a href="1996_en_informatique" title="1996 en informatique">1996</a></time>, la <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 1945<a href="#cite_note-RFC-1945-1">[1]</a> décrit HTTP tel que communément implémenté à l'époque et connu sous le nom de HTTP/1.0. Cette version supporte la gestion de cache et l'identification.

En <time class="nowrap date-lien" datetime="1997-01" data-sort-value="1997-01"><a href="Janvier_1997" title="Janvier 1997">janvier</a> <a href="1997_en_informatique" title="1997 en informatique">1997</a></time>, HTTP/1.1 devient finalement standard de l'<a href="Internet_Engineering_Task_Force" title="Internet Engineering Task Force">IETF</a>. Il est décrit dans la <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2068<a href="#cite_note-RFC-2068-2">[2]</a> de l'IETF, puis dans la <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2616<a href="#cite_note-RFC-2616-3">[3]</a> en <time class="nowrap date-lien" datetime="1999-06" data-sort-value="1999-06"><a href="Juin_1999" title="Juin 1999">juin</a> <a href="1999_en_informatique" title="1999 en informatique">1999</a></time>. Cette version ajoute le support du transfert en <a href="Pipelining_HTTP" title="Pipelining HTTP">pipeline</a> (ou pipelinage) et la négociation de type de contenu (format de données, langue). HTTP/1.1 rend la présence de l'entête <code>Host</code> obligatoire dans les requêtes afin de supporter l'<a href="H%C3%A9bergement_mutualis%C3%A9" title="Hébergement mutualisé">hébergement mutualisé</a>.

En <time class="nowrap date-lien" datetime="2012-03" data-sort-value="2012-03"><a href="Mars_2012" title="Mars 2012">mars</a> <a href="2012_en_informatique" title="2012 en informatique">2012</a></time>, les travaux à propos de HTTP/2.0 démarrent à l'IETF adoptant SPDY comme matériel de départ.

En <time class="nowrap date-lien" datetime="2014-02" data-sort-value="2014-02"><a href="F%C3%A9vrier_2014" title="Février 2014">février</a> <a href="2014_en_informatique" title="2014 en informatique">2014</a></time>, la spécification de HTTP 1.1 a été republiée. Elle a été éclatée en plusieurs RFC et corrigée pour toutes ses imprécisions, <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7230<a href="#cite_note-RFC-7230-4">[4]</a> à <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7237<a href="#cite_note-RFC-7237-5">[5]</a>.

<div class="mw-heading mw-heading2"><h2 id="Implémentation">Implémentation</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Méthodes">Méthodes</h3></div>

Dans le protocole HTTP, une méthode est une commande spécifiant un type de requête, c'est-à-dire qu'elle demande au serveur d'effectuer une action. En général l'action concerne une ressource identifiée par l'<a href="Uniform_Resource_Locator" title="Uniform Resource Locator">URL</a> qui suit le nom de la méthode.

Dans l'illustration ci-contre, une requête GET est envoyée pour récupérer la page d'accueil du site web www.perdu.com :

<pre>GET / HTTP/1.1

Host: www.perdu.com

</pre>

Il existe de nombreuses méthodes, les plus courantes étant GET, HEAD et POST :

<dd>C'est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet.</dd>

<dd>Cette méthode ne demande que des informations sur la ressource, sans demander la ressource elle-même.</dd>

<dd>Cette méthode est utilisée pour transmettre des données en vue d'un traitement à une ressource (le plus souvent depuis un formulaire HTML). L'<a href="Uniform_Resource_Identifier" title="Uniform Resource Identifier">URI</a> fourni est l'URI d'une ressource à laquelle s'appliqueront les données envoyées. Le résultat peut être la création de nouvelles ressources ou la modification de ressources existantes. À cause de la mauvaise implémentation des méthodes HTTP (pour <a href="Asynchronous_JavaScript_and_XML" class="mw-redirect" title="Asynchronous JavaScript and XML">Ajax</a>) par certains navigateurs (et la norme <a href="HTML" class="mw-redirect" title="HTML">HTML</a> qui ne supporte que les méthodes GET et POST pour les formulaires), cette méthode est souvent utilisée en remplacement de la requête PUT, qui devrait être utilisée pour la mise à jour de ressources.</dd>

<dt><code>OPTIONS</code></dt>

<dd>Cette méthode permet d'obtenir les options de communication d'une ressource ou du serveur en général.</dd>

<dt><code>CONNECT</code></dt>

<dd>Cette méthode permet d'utiliser un proxy comme un tunnel de communication.</dd>

<dt><code>TRACE</code></dt>

<dd>Cette méthode demande au serveur de retourner ce qu'il a reçu, dans le but de tester et effectuer un diagnostic sur la connexion.</dd>

<dd>Cette méthode permet de remplacer ou d'ajouter une ressource sur le serveur. L'URI fourni est celui de la ressource en question.</dd>

<dt><code>PATCH</code></dt>

<dd>Cette méthode permet, contrairement à PUT, de faire une modification partielle d'une ressource.</dd>

<dt><code>DELETE</code></dt>

<dd>Cette méthode permet de supprimer une ressource du serveur.</dd></dl>

Ces 3 dernières méthodes nécessitent généralement un accès privilégié.

Certains serveurs autorisent d'autres méthodes de gestion de leurs ressources (par exemple <a href="WebDAV" title="WebDAV">WebDAV</a>).

<div class="mw-heading mw-heading3"><h3 id="Du_client_au_serveur">Du client au serveur</h3></div>

La liaison entre le client et le serveur n'est pas toujours directe, il peut exister des machines intermédiaires servant de relais :

<ul><li>Un <a href="Proxy" title="Proxy">proxy</a> (ou serveur mandataire) peut modifier les réponses et requêtes qu'il reçoit et peut gérer un cache des ressources demandées.</li>

<li>Une <a href="Passerelle_(informatique)" title="Passerelle (informatique)">passerelle</a> (ou gateway) est un intermédiaire modifiant le protocole utilisé.</li>

<li>Un <a href="Tunnel_(r%C3%A9seau_informatique)" title="Tunnel (réseau informatique)">tunnel</a> transmet les requêtes et les réponses sans aucune modification, ni mise en cache.</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Identification">Identification</h3></div>

HTTP permet l'<a href="HTTP_Authentification" class="mw-redirect" title="HTTP Authentification">identification</a> du visiteur par transmission d'un nom et d'un <a href="Mot_de_passe" title="Mot de passe">mot de passe</a>.

Il existe deux modes d'identification : Basic et Digest (<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2617<a href="#cite_note-RFC-2617-6">[6]</a>). Le premier mode transmet le mot de passe en clair et ne doit donc être utilisé qu'avec le protocole HTTPS. Le deuxième mode permet une identification sans transmettre le mot de passe en clair.

L'identification est, cependant souvent effectuée par une couche applicative supérieure à HTTP.

<div class="mw-heading mw-heading3"><h3 id="Liste_de_serveurs_HTTP">Liste de serveurs HTTP</h3></div>

<ul><li>C : <a href="Apache_HTTP_Server" title="Apache HTTP Server">Apache</a>, <a href="Zeus_Web_Server" title="Zeus Web Server">Zeus Web Server</a>, <a href="Nginx" class="mw-redirect" title="Nginx">nginx</a>, <a href="Lighttpd" title="Lighttpd">lighttpd</a>, <a href="Cherokee_Web_Server" title="Cherokee Web Server">Cherokee</a>, <a href="Hiawatha_(serveur_HTTP)" title="Hiawatha (serveur HTTP)">Hiawatha Webserver</a></li>

<li>Java : <a href="Apache_Tomcat" title="Apache Tomcat">Tomcat</a>, <a href="Jetty" title="Jetty">Jetty</a>, <a href="GlassFish" title="GlassFish">GlassFish</a>, <a href="JBoss" class="mw-redirect" title="JBoss">JBoss (WildFly dans les nouvelles versions)</a>, <a href="JOnAS" title="JOnAS">JOnAS</a>, <a href="Vert.x" title="Vert.x">Vert.x</a></li>

<li>Python : <a href="Zope" title="Zope">Zope</a></li>

<li>Pike : <a href="Caudium_(logiciel)" title="Caudium (logiciel)">Caudium</a></li>

<li>Ruby : <a href="WEBrick" title="WEBrick">WEBrick</a>, <a href="Mongrel_(serveur_HTTP)" title="Mongrel (serveur HTTP)">Mongrel</a>, Thin<a href="#cite_note-7">[7]</a></li>

<li>Erlang : <a href="Yaws" title="Yaws">Yaws</a></li>

<li><a href="JavaScript" title="JavaScript">Javascript</a> : <a href="Express.js" title="Express.js">Express.js</a></li>

<li>Autres : <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a href="https://en.wikipedia.org/wiki/Comparison_of_web_servers" class="extiw external" title="en:Comparison of web servers">Comparison of web servers</a></li></ul>

<div class="mw-heading mw-heading3"><h3 id="Versions">Versions</h3></div>

Au début du <a href="World_Wide_Web" title="World Wide Web">World Wide Web</a>, il était prévu d'ajouter au protocole HTTP des capacités de <a href="N%C3%A9gociation_de_contenu" title="Négociation de contenu">négociation de contenu</a>, en s'inspirant notamment de <a href="Multipurpose_Internet_Mail_Extensions" title="Multipurpose Internet Mail Extensions">MIME</a>. En attendant, le protocole HTTP 0.9 était extrêmement simple.

<ol><li>connexion du <a href="Client_HTTP" title="Client HTTP">client HTTP</a></li>

<li>envoi d'une requête de méthode <code>GET</code></li>

<li>réponse du <a href="Serveur_HTTP" class="mw-redirect" title="Serveur HTTP">serveur HTTP</a></li>

<li>le serveur ferme la connexion pour signaler la fin de la réponse</li></ol>

Requête :

<pre>GET /page.html

</pre>

La méthode <code>GET</code> est la seule possible. Le serveur reconnaît qu'il a affaire à une requête HTTP 0.9 au fait que la version n'est pas précisée à la suite de l'URI.

Réponse :

<pre> <TITLE>Exemple</TITLE>

<H1>Exemple</H1>Ceci est une page d'exemple.

</pre>

Pour répondre à une requête HTTP 0.9, le serveur envoie directement le contenu de la réponse, sans métadonnées. Il ne doit jamais se comporter ainsi pour les requêtes HTTP de version supérieure.

Inutile de chercher les versions inférieures à 0.9 du protocole HTTP : elles n'existent pas, car HTTP 0.9 n'avait initialement pas de numéro de version. Il a fallu lui en attribuer un quand HTTP 1.0 est arrivé.

Le protocole HTTP 1.0, décrit dans la <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 1945<a href="#cite_note-RFC-1945-1">[1]</a>, prévoit l'utilisation d'<a href="Header" title="Header">en-têtes</a> spécifiés dans la <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 822<a href="#cite_note-RFC-822-8">[8]</a>. La gestion de la connexion reste identique à HTTP 0.9 : le client établit la connexion, envoie une requête, le serveur répond et ferme immédiatement la connexion.

Une requête HTTP présente le format suivant :

<pre> Ligne de commande (Commande, URL, Version de protocole)

En-tête de requête

[Ligne vide]

Corps de requête

</pre>

Les réponses HTTP présentent le format suivant :

<pre> Ligne de statut (Version, Code-réponse, Texte-réponse)

En-tête de réponse

[Ligne vide]

Corps de réponse

</pre>

Requête :

<pre>GET /page.html HTTP/1.0

Host: example.com

Referer: http://example.com/

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

</pre>

La version du protocole HTTP est précisée à la suite de l'URI. La requête doit être terminée par un double retour à la ligne (<a href="CRLF" class="mw-redirect" title="CRLF">CRLFCRLF</a>). HTTP 1.0 supporte aussi les méthodes HEAD et POST.

On constate l'usage d'en-têtes inspirés de <a href="Multipurpose_Internet_Mail_Extensions" title="Multipurpose Internet Mail Extensions">MIME</a> pour transférer les métadonnées :

<dd>Permet de préciser le <a href="Site_web" title="Site web">site web</a> concerné par la requête, ce qui est nécessaire pour un serveur hébergeant plusieurs sites à la même <a href="Adresse_IP" title="Adresse IP">adresse IP</a> (name based virtual host, hôte virtuel basé sur le nom). C'est le seul en-tête réellement important.</dd>

<dt><code>Referer</code></dt>

<dd>Indique l'<a href="Uniform_Resource_Identifier" title="Uniform Resource Identifier">URI</a> du document qui a donné un lien sur la ressource demandée. Cet en-tête permet aux <a href="Webmestre" class="mw-redirect" title="Webmestre">webmasters</a> d'observer d'où viennent les visiteurs.</dd>

<dt><code>User-Agent</code></dt>

<dd>Indique le logiciel utilisé pour se connecter. Il s'agit généralement d'un <a href="Navigateur_web" title="Navigateur web">navigateur web</a> ou d'un <a href="Robot_d'indexation" title="Robot d'indexation">robot d'indexation</a>.</dd></dl>

Réponse :

<pre>HTTP/1.0 200 OK

Date: Fri, 31 Dec 1999 23:59:59 GMT

Server: Apache/0.8.4

Content-Type: text/html

Content-Length: 59

Expires: Sat, 01 Jan 2000 00:59:59 GMT

Last-modified: Fri, 09 Aug 1996 14:21:40 GMT

<TITLE>Exemple</TITLE>

Ceci est une page d'exemple.

</pre>

La première ligne donne le <a href="Liste_des_codes_HTTP" title="Liste des codes HTTP">code de statut HTTP</a> (200 dans ce cas).

<dd>Moment auquel le message est généré.</dd>

<dt><code>Server</code></dt>

<dd>Indique quel modèle de <a href="Serveur_HTTP" class="mw-redirect" title="Serveur HTTP">serveur HTTP</a> répond à la requête.</dd>

<dt><code>Content-Type</code></dt>

<dd>Indique le type <a href="Multipurpose_Internet_Mail_Extensions" title="Multipurpose Internet Mail Extensions">MIME</a> de la ressource.</dd>

<dt><code>Content-Length</code></dt>

<dd>Indique la taille en <a href="Octet" title="Octet">octets</a> de la ressource.</dd>

<dt><code>Expires</code></dt>

<dd>Indique le moment après lequel la ressource devrait être considérée obsolète ; permet aux navigateurs Web de déterminer jusqu'à quand garder la ressource en <a href="M%C3%A9moire_cache" title="Mémoire cache">mémoire cache</a>.</dd>

<dt><code>Last-Modified</code></dt>

<dd>Indique la date de dernière modification de la ressource demandée.</dd></dl>

Le protocole HTTP 1.1 est décrit par le <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2616<a href="#cite_note-RFC-2616-3">[3]</a> qui rend le <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2068<a href="#cite_note-RFC-2068-2">[2]</a> obsolète.

La différence avec HTTP 1.0 est une meilleure gestion du cache. L'en-tête Host devient obligatoire dans les requêtes.

Les soucis majeurs des deux premières versions du protocole HTTP sont d'une part le nombre important de connexions lors du chargement d'une page complexe (contenant beaucoup d'images ou d'animations) et d'autre part le temps d'ouverture d'une connexion entre client et serveur (l'<a href="Transmission_Control_Protocol#Établissement_d'une_connexion" title="Transmission Control Protocol">établissement d'une connexion TCP</a> prend un temps triple de la latence entre client et serveur). Des expérimentations de connexions persistantes ont cependant été effectuées avec HTTP 1.0 (notamment par l'emploi de l'en-tête Connection: Keep-Alive), mais cela n'a été définitivement mis au point qu'avec HTTP 1.1.

Par défaut, HTTP 1.1 utilise des connexions persistantes, autrement dit la connexion n'est pas immédiatement fermée après une requête, mais reste disponible pour une nouvelle requête. On appelle souvent cette fonctionnalité keep-alive. Il est aussi permis à un client HTTP d'envoyer plusieurs requêtes sur la même connexion sans attendre les réponses. On appelle cette fonctionnalité <a href="Pipelining_HTTP" title="Pipelining HTTP">pipelining</a>. La persistance des connexions permet d'accélérer le chargement de pages contenant plusieurs ressources, tout en diminuant la charge du réseau.

La gestion de la persistance d'une connexion est gérée par l'en-tête Connection.

HTTP 1.1 supporte la négociation de contenu. Un client HTTP 1.1 peut accompagner la requête pour une ressource d'en-têtes indiquant quels sont les <a href="Langue" title="Langue">langues</a> et <a href="Format_de_donn%C3%A9es" title="Format de données">formats de données</a> préférés.

Il s'agit des en-têtes dont le nom commence par Accept-.

Les en-têtes supplémentaires supportés par HTTP 1.1 sont :

<dl><dt><code>Connection</code></dt>

<dd>Cet en-tête peut être envoyé par le client ou le serveur et contient une liste de noms spécifiant les options à utiliser avec la connexion actuelle. Si une option possède des paramètres ceux-ci sont spécifiés par l'en-tête portant le même nom que l'option (Keep-Alive par exemple, pour spécifier le nombre maximum de requêtes par connexion). Le nom close est réservé pour spécifier que la connexion doit être fermée après traitement de la requête en cours.</dd>

<dt><code>Accept</code></dt>

<dd>Cet en-tête liste les types MIME de contenu acceptés par le client. Le caractère étoile * peut servir à spécifier tous les types / sous-types.</dd>

<dt><code>Accept-Charset</code></dt>

<dd>Spécifie les encodages de caractères acceptés.</dd>

<dt><code>Accept-Language</code></dt>

<dd>Spécifie les langues acceptées.</dd></dl>

L'ordre de préférence de chaque option (type, encodage ou langue) est spécifié par le paramètre optionnel q contenant une valeur décimale entre 0 (inacceptable) et 1 (acceptable) inclus (3 décimales maximum après la virgule), valant 1 par défaut.

Le support des connexions persistantes doit également fonctionner dans les cas où la taille de la ressource n'est pas connue d'avance (ressource générée dynamiquement par le serveur, flux externe au serveur…).

Pour cela, l'encodage de transfert nommé chunked permet de transmettre la ressource par morceaux consécutifs en précédant chacun par une ligne de texte donnant la taille de celui-ci en hexadécimal. Le transfert se termine alors par un morceau de taille nulle, où des en-têtes finaux peuvent être envoyés.

Les en-têtes supplémentaires liés à cet encodage de transfert sont :

<dl><dt><code>Transfer-Encoding</code></dt>

<dd>Spécifie l'encodage de transfert. La seule valeur définie par la spécification <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2616<a href="#cite_note-RFC-2616-3">[3]</a> est chunked.</dd></dl>

<dl><dt><code>Trailer</code></dt>

<dd>Liste tous les en-têtes figurant après le dernier morceau transféré.</dd>

<dd>Envoyé par le client pour spécifier les encodages de contenu supportés (Content-Encoding, ne pas confondre avec Transfer-Encoding car chunked est obligatoirement supporté par les clients et serveurs implémentant le standard HTTP/1.1), et spécifie si le client supporte l'en-tête Trailer en ajoutant trailers à la liste.</dd></dl>

<abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2616<a href="#cite_note-RFC-2616-3">[3]</a> comprenait de nombreuses imprécisions. Le groupe de travail HTTP a pris quelques années afin de clarifier la spécification sans en modifier la sémantique tel que préconisé dans la charte de fonctionnement du groupe pour ce travail. En <time class="nowrap" datetime="2014-06" data-sort-value="2014-06">juin 2014</time>, huit nouveaux documents ont été publiés qui rendent obsolète la <abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 2616<a href="#cite_note-RFC-2616-3">[3]</a> :

<ul><li><abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7230<a href="#cite_note-RFC-7230-4">[4]</a> Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (Standard proposé)</li>

<li><abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7231<a href="#cite_note-RFC-7231-9">[9]</a> Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (Standard proposé)</li>

<li><abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7232<a href="#cite_note-RFC-7232-10">[10]</a> Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests (Standard proposé)</li>

<li><abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7233<a href="#cite_note-RFC-7233-11">[11]</a> Hypertext Transfer Protocol (HTTP/1.1): Range Requests (Standard proposé)</li>

<li><abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7234<a href="#cite_note-RFC-7234-12">[12]</a> Hypertext Transfer Protocol (HTTP/1.1): Caching (Standard proposé)</li>

<li><abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7235<a href="#cite_note-RFC-7235-13">[13]</a> Hypertext Transfer Protocol (HTTP/1.1): Authentication (Standard proposé)</li>

<li><abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7236<a href="#cite_note-RFC-7236-14">[14]</a> Hypertext Transfer Protocol (HTTP/1.1): Authentication Scheme Registrations (Information)</li>

<li><abbr class="abbr" title="Request for comments" lang="en">RFC</abbr> 7237<a href="#cite_note-RFC-7237-5">[5]</a> Hypertext Transfer Protocol (HTTP/1.1): Method Registrations (Information)</li></ul>

Une nouvelle version d'HTTP, HTTP/2, a été développée au sein du groupe de travail « Hypertext Transfer Protocol Bis » (httpbis) de l'<a href="Internet_Engineering_Task_Force" title="Internet Engineering Task Force">Internet Engineering Task Force</a><a href="#cite_note-15">[15]</a> et approuvée comme RFC standard le <time class="nowrap" datetime="2015-02-18" data-sort-value="2015-02-18">18 février 2015</time><a href="#cite_note-16">[16]</a>.

Le développement d'HTTP/2 a débuté à la suite de la création du protocole <a href="SPDY" title="SPDY">SPDY</a> proposé par <a href="Google" title="Google">Google</a> afin de réduire le temps de chargement des pages Web<a href="#cite_note-17">[17]</a>,<a href="#cite_note-18">[18]</a>. Le groupe de travail httpbis s'était initialement interdit de proposer une nouvelle version d'HTTP, concentrant son activité sur la clarification des spécifications d'HTTP 1.1. Considérant l'arrivée de SPDY et son adoption rapide sur le Web, avec notamment des implémentations dans deux des principaux <a href="Navigateur_web" title="Navigateur web">navigateurs Web</a>, <a href="Google_Chrome" title="Google Chrome">Google Chrome</a> et <a href="Mozilla_Firefox" title="Mozilla Firefox">Mozilla Firefox</a>, Mark Nottingham, « chair » d'httpbis, a émis l'opinion qu'il était temps d'envisager HTTP/2 et proposé d'amender la charte d'httpbis en ce sens, initiant de fait le développement du nouveau protocole<a href="#cite_note-19">[19]</a>.

SPDY constituait une option naturelle pour servir de base à HTTP/2. Deux autres propositions concurrentes ont été ensuite transmises à l'IETF : le protocole « HTTP Speed+Mobility » par <a href="Microsoft" title="Microsoft">Microsoft</a><a href="#cite_note-20">[20]</a> et une proposition de mise à jour d'HTTP (« Network-Friendly HTTP Upgrade »)<a href="#cite_note-21">[21]</a>. En <time class="nowrap" datetime="2012-07" data-sort-value="2012-07">juillet 2012</time>, httpbis a publié un appel à expression d'intérêt (« Call for Expression of Interest ») afin de recueillir l'avis d'acteurs du Web sur les propositions<a href="#cite_note-22">[22]</a>. Parmi les réponses obtenues figure celle de <a href="Facebook" title="Facebook">Facebook</a> qui a signifié sa préférence pour SPDY<a href="#cite_note-23">[23]</a>. En <time class="nowrap" datetime="2012-11" data-sort-value="2012-11">novembre 2012</time>, l'IETF a publié le premier draft d'HTTP/2, qui est une copie directe de SPDY<a href="#cite_note-24">[24]</a>.

Après plus de deux ans de discussions, la RFC est approuvée en <time class="nowrap" datetime="2015-02" data-sort-value="2015-02">février 2015</time> par le groupe de pilotage de l'IETF, et est publiée en <time class="nowrap" datetime="2015-05" data-sort-value="2015-05">mai 2015</time>.

Le module permettant la prise en charge du protocole HTTP/2 est disponible depuis la version 2.4.17<a href="#cite_note-25">[25]</a> du serveur Web Apache, et depuis la version 1.9.5<a href="#cite_note-26">[26]</a> de Nginx.

Une nouvelle version d’HTTP, HTTP/3, est la troisième et prochaine version majeure du protocole de transfert hypertexte utilisé pour échanger des informations sur le World Wide Web. Celle-ci repose sur le protocole <a href="QUIC" title="QUIC">QUIC</a>, développé par Google en 2012.

La sémantique HTTP est cohérente d'une version à l'autre. En effet, les mêmes méthodes de requête, codes de statut et champs de message sont généralement applicables à toutes les versions.

Si HTTP/1 et HTTP/2 utilisent tous deux TCP comme protocole de transport, HTTP/3 quant à lui utilise le protocole <a href="QUIC" title="QUIC">QUIC</a>, un protocole de la couche transport qui est plus adapté au Web. Le passage à <a href="QUIC" title="QUIC">QUIC</a> vise à résoudre un problème majeur de HTTP/2 appelé « Head-of-line Blocking » grâce à une encapsulation des paquets dans UDP. En effet, avec HTTP/2 reposant sur TCP, une connexion permet d'accéder aux ressources demandées une à une (une seule à la fois). Lorsque l'envoi d’une ressource est perturbé (par exemple par une perte de paquets), la livraison globale des ressources est ralentie. Avec HTTP/3 reposant sur le protocole <a href="QUIC" title="QUIC">QUIC</a>, ce problème n'est plus, puisque tous les flux sont indépendants étant encapsulés dans UDP, protocole de transport ne nécessitant pas de connexion.

<div class="mw-heading mw-heading2"><h2 id="Notes_et_références">Notes et références</h2></div>

<li id="cite_note-RFC-1945-1"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc1945">Request for comments <abbr class="abbr" title="numéro">no</abbr> 1945</a>

</li>

<li id="cite_note-RFC-2068-2"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc2068">Request for comments <abbr class="abbr" title="numéro">no</abbr> 2068</a>

</li>

<li id="cite_note-RFC-2616-3"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc2616">Request for comments <abbr class="abbr" title="numéro">no</abbr> 2616</a>

</li>

<li id="cite_note-RFC-7230-4"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc7230">Request for comments <abbr class="abbr" title="numéro">no</abbr> 7230</a>

</li>

<li id="cite_note-RFC-7237-5"><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc7237">Request for comments <abbr class="abbr" title="numéro">no</abbr> 7237</a>

</li>

<li id="cite_note-RFC-2617-6"><a href="#cite_ref-RFC-2617_6-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc2617">Request for comments <abbr class="abbr" title="numéro">no</abbr> 2617</a>

</li>

<li id="cite_note-7"><a href="#cite_ref-7">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="https://github.com/macournoyer/thin"><cite style="font-style:normal;" lang="en">Macournoyer/thin : A very fast & simple Ruby web server</cite></a> », sur GitHub (consulté le <time class="nowrap" datetime="2023-10-15" data-sort-value="2023-10-15">15 octobre 2023</time>).

</li>

<li id="cite_note-RFC-822-8"><a href="#cite_ref-RFC-822_8-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc822">Request for comments <abbr class="abbr" title="numéro">no</abbr> 822</a>

</li>

<li id="cite_note-RFC-7231-9"><a href="#cite_ref-RFC-7231_9-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc7231">Request for comments <abbr class="abbr" title="numéro">no</abbr> 7231</a>

</li>

<li id="cite_note-RFC-7232-10"><a href="#cite_ref-RFC-7232_10-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc7232">Request for comments <abbr class="abbr" title="numéro">no</abbr> 7232</a>

</li>

<li id="cite_note-RFC-7233-11"><a href="#cite_ref-RFC-7233_11-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc7233">Request for comments <abbr class="abbr" title="numéro">no</abbr> 7233</a>

</li>

<li id="cite_note-RFC-7234-12"><a href="#cite_ref-RFC-7234_12-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc7234">Request for comments <abbr class="abbr" title="numéro">no</abbr> 7234</a>

</li>

<li id="cite_note-RFC-7235-13"><a href="#cite_ref-RFC-7235_13-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc7235">Request for comments <abbr class="abbr" title="numéro">no</abbr> 7235</a>

</li>

<li id="cite_note-RFC-7236-14"><a href="#cite_ref-RFC-7236_14-0">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://tools.ietf.org/html/rfc7236">Request for comments <abbr class="abbr" title="numéro">no</abbr> 7236</a>

</li>

<li id="cite_note-15"><a href="#cite_ref-15">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="https://datatracker.ietf.org/wg/httpbis/charter/"><cite style="font-style:normal;" lang="en">Hypertext Transfer Protocol Bis (httpbis)</cite></a> », sur datatracker.ietf.org (consulté le <time class="nowrap" datetime="2013-11-14" data-sort-value="2013-11-14">14 novembre 2013</time>).

</li>

<li id="cite_note-16"><a href="#cite_ref-16">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="http://www.ietf.org/blog/2015/02/http2-approved/"><cite style="font-style:normal;" lang="en">HTTP/2 Approved</cite></a> », sur ietf.org (consulté le <time class="nowrap" datetime="2015-02-19" data-sort-value="2015-02-19">19 février 2015</time>).

</li>

<li id="cite_note-17"><a href="#cite_ref-17">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="https://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper"><cite style="font-style:normal;" lang="en">SPDY: An experimental protocol for a faster web</cite></a> » (consulté le <time class="nowrap" datetime="2013-11-14" data-sort-value="2013-11-14">14 novembre 2013</time>).

</li>

<li id="cite_note-18"><a href="#cite_ref-18">↑</a> « <a rel="nofollow" class="external text" href="http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00"><cite style="font-style:normal;">SPDY Protocol (Internet draft)</cite></a> », <time class="nowrap" datetime="2012-02" data-sort-value="2012-02">février 2012</time>.

</li>

<li id="cite_note-19"><a href="#cite_ref-19">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Mark Nottingham, « <a rel="nofollow" class="external text" href="http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0098.html"><cite style="font-style:normal;" lang="en">Rechartering HTTPbis</cite></a> », sur lists.w3.org, <time class="nowrap" datetime="2012-01-24" data-sort-value="2012-01-24">24 janvier 2012</time> (consulté le <time class="nowrap" datetime="2013-11-14" data-sort-value="2013-11-14">14 novembre 2013</time>).

</li>

<li id="cite_note-20"><a href="#cite_ref-20">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-02"><cite style="font-style:normal;" lang="en">HTTP Speed+Mobility (Internet draft)</cite></a> », <time class="nowrap" datetime="2012-06-15" data-sort-value="2012-06-15">15 juin 2012</time>.

</li>

<li id="cite_note-21"><a href="#cite_ref-21">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00"><cite style="font-style:normal;" lang="en">Proposal for a Network-Friendly HTTP Upgrade</cite></a> », <time class="nowrap" datetime="2012-03-29" data-sort-value="2012-03-29">29 mars 2012</time>.

</li>

<li id="cite_note-22"><a href="#cite_ref-22">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI"><cite style="font-style:normal;" lang="en">Call for Expressions of Interest</cite></a> », sur ietf.org, <time class="nowrap" datetime="2012-07-03" data-sort-value="2012-07-03">3 juillet 2012</time>.

</li>

<li id="cite_note-23"><a href="#cite_ref-23">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> « <a rel="nofollow" class="external text" href="http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0251.html"><cite style="font-style:normal;" lang="en">HTTP2 Expression of Interest</cite></a> », <time class="nowrap" datetime="2012-07-15" data-sort-value="2012-07-15">15 juillet 2012</time>.

</li>

<li id="cite_note-24"><a href="#cite_ref-24">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> Dio Synodinos, « <a rel="nofollow" class="external text" href="http://www.infoq.com/news/2012/11/http20-first-draft"><cite style="font-style:normal;" lang="en">HTTP 2.0 First Draft Published</cite></a> », sur InfoQ, <time class="nowrap" datetime="2012-11-30" data-sort-value="2012-11-30">30 novembre 2012</time>.

</li>

<li id="cite_note-25"><a href="#cite_ref-25">↑</a> « <a rel="nofollow" class="external text" href="https://httpd.apache.org/docs/2.4/mod/mod_http2.html"><cite style="font-style:normal;">Apache Module mod_http2</cite></a> », sur httpd.apache.org.

</li>

<li id="cite_note-26"><a href="#cite_ref-26">↑</a> <abbr class="abbr indicateur-langue" title="Langue : anglais américain">(en-US)</abbr> « <a rel="nofollow" class="external text" href="https://www.nginx.com/blog/nginx-1-9-5/"><cite style="font-style:normal;" lang="en-us">HTTP/2 Supported in Open Source NGINX 1.9.5</cite></a> », sur NGINX, <time class="nowrap" datetime="2015-09-22" data-sort-value="2015-09-22">22 septembre 2015</time> (consulté le <time class="nowrap" datetime="2019-07-03" data-sort-value="2019-07-03">3 juillet 2019</time>).

</li>

</ol>

</div>

<div class="mw-heading mw-heading2"><h2 id="Voir_aussi">Voir aussi</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Articles_connexes">Articles connexes</h3></div>

<ul><li><a href="Liste_des_codes_HTTP" title="Liste des codes HTTP">Liste des codes HTTP</a></li>

<li><a href="Navigateur_web" title="Navigateur web">Navigateur web</a></li>

<li><a href="Pipelining_HTTP" title="Pipelining HTTP">Pipelining HTTP</a></li>

<li><a href="Protocole_de_communication" title="Protocole de communication">Protocole de communication</a></li>

<li><a href="Serveur_HTTP" class="mw-redirect" title="Serveur HTTP">Serveur HTTP</a></li>

<li><a href="World_Wide_Web" title="World Wide Web">World Wide Web</a></li>

<li><a href="Hypertext_Transfer_Protocol_Secure" title="Hypertext Transfer Protocol Secure">HTTPS</a></li></ul>

</div>

<div class="mw-heading mw-heading3"><h3 id="Liens_externes">Liens externes</h3></div>

<ul><li><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://www.w3.org/Protocols/">HTTP - Hypertext Transfer Protocol</a> sur le site du <a href="W3C" class="mw-redirect" title="W3C">W3C</a></li>

<li><a href="https://datatracker.ietf.org/doc/html/rfc1945" class="extiw external" title="rfc:1945">RFC 1945</a>, Hypertext Transfer Protocol -- HTTP/1.0</li>

<li><a href="https://datatracker.ietf.org/doc/html/rfc2616" class="extiw external" title="rfc:2616">RFC 2616</a>, Hypertext Transfer Protocol -- HTTP/1.1</li>

<li><a href="https://datatracker.ietf.org/doc/html/rfc2617" class="extiw external" title="rfc:2617">RFC 2617</a> HTTP Authentification: Basic and Digest Access Authentification</li>

<li><a href="https://datatracker.ietf.org/doc/html/rfc7230" class="extiw external" title="rfc:7230">RFC 7230</a>, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</li>

<li><a href="https://datatracker.ietf.org/doc/html/rfc7231" class="extiw external" title="rfc:7231">RFC 7231</a>, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</li>

<li><a href="https://datatracker.ietf.org/doc/html/rfc7232" class="extiw external" title="rfc:7232">RFC 7232</a>, Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</li>

<li><a href="https://datatracker.ietf.org/doc/html/rfc7233" class="extiw external" title="rfc:7233">RFC 7233</a>, Hypertext Transfer Protocol (HTTP/1.1): Range Requests</li>

<li><a href="https://datatracker.ietf.org/doc/html/rfc7234" class="extiw external" title="rfc:7234">RFC 7234</a>, Hypertext Transfer Protocol (HTTP/1.1): Caching</li>

<li><a href="https://datatracker.ietf.org/doc/html/rfc7538" class="extiw external" title="rfc:7538">RFC 7538</a>, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)</li>

<li><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="http://www.w3.org/Protocols/rfc1945/rfc1945.txt">Hypertext Transfer Protocol 1.0</a> sur le site du W3C</li>

<li><abbr class="abbr indicateur-langue" title="Langue : anglais">(en)</abbr> <a rel="nofollow" class="external text" href="https://hpbn.co/">High Performance Browser Networking</a>, Ilya Grigorik, 2013.</li></ul>

</div>

</div>

<ul id="bandeau-portail" class="bandeau-portail"><li> Portail des réseaux informatiques </li> <li> Portail de l’informatique </li> <li> Portail des télécommunications </li> <li> Portail d’Internet </li> <li> Portail du Web sémantique </li> </ul></div><div><div class="zim-footer">

Cet article est issu de <a class="external text" title="Dernière modification le 2025-07-09" href="https://fr.wikipedia.org/wiki/?title=Hypertext_Transfer_Protocol&oldid=227153874">Wikipédia</a>. Sauf mention contraire, le texte est disponible sous <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.fr">Creative Commons Attribution-Share Alike 4.0</a>. Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.

</div>

</div></div>

</div>

</main>

</div>

</body></html>